Specifying Use Case Interaction: Types of Alternative Courses

Use cases are a powerful and widely recognised tool for the elicitation and specification of functional software requirements. However, major problems and gaps still exist; practitioners frequently encounter these. One of these is the specification of alternative use case interaction courses. Experience shows that practitioners do not only need to specify alternative interaction courses that are inserted subject to a business condition; they also need to express partially or fully parallel interaction courses, exceptional use case behaviour, and cyclic interaction paths. Based on an extensive literature review and practical observations, this paper provides definitions for types of alternative interaction courses, as well as clarifying conceptual differences between, and providing illustrative real-world examples of, each. Moreover, these definitions are related to Cockburn’s relevant practical approach of use case goals and use case business results in the context of goal-driven requirements engineering. Finally, the provided definitions will contribute to an understanding of use case interaction specification and goal-driven requirements engineering in practice; they also present clear advice on how to perform use case model refactoring through the application of UML’s repeatedly discussed extend-relationship. 1 BRIEF HISTORY OF USE CASE BASICS Goals and Interaction Courses An actor specifies a role that can be taken by a person, a piece of hardware, a specific date/time, or a software component [4], [7]. [10], [11]. Each actor has certain operational responsibilities imposed by the business processes and business rules of the business domain. In order to fulfil its responsibilities, the actor has to perform a number of operations. An actor wants some subset of these operations to be facilitated by a software application or hardware apparatus. Thus, it sets corresponding goals for the system to SPECIFIYING USE CASE INTERACTION: TYPES OF ALTERNATIVE COURSES 112 JOURNAL OF OBJECT TECHNOLOGY VOL. 2, NO. 2 deliver. These goals lead to desired system functionalities expressed by use cases [3]; each use case delivers a single goal. A goal needs to be accomplished; therefore, some action has to be taken to achieve it. Hence, a use case goal leads to an interaction with a system in order to deliver this use case goal. The interaction description of a use case encompasses two parts [7]: a Basic Course describes the main sequence of interaction in which everything goes right (“happy path”, see Example 1), whereas any non-frequent alternative or interruption from the basic course of interaction, such as optional parts of behaviour, alternative interaction parts, business error recovery and fault-handling, is called an Alternative Course [7] (see Example 1). In this sense, the term Alternative Course specifies a guarded variation of a part of another interaction course (see Figure 2) and, thus, is subject to some business condition. The location where an alternative course branches to another interaction course is called an Extension Point. It should be noted that, originally, UML introduced the term extension point to indicate branching locations for the extend-relationship only [2]; an extend-relationship is used to attach extracted optional behaviour, that resides in an additional use case, to its base use case. However, we consider the term extension point also applicable to branching points of alternative courses that remain local textual use case properties since this reduces the number of terms needed. Example 1 shows an example of a basic course and an alternative that follows the specification technique in [3]. Example 1: Consider a use case with the goal “Register New Student”. Further consider the following fragment of the basic course: 1. Clerk enters new student’s name, address, ... 2. The system assigns a student ID. 3. Clerk assigns the university department. 4. System prints out a confirmation of registration. 5. ... University Administration Clerk of the central student affairs dept. Register New Student Figure 1: Use Case Diagram for Example 1 Now consider the following alternative course: BRIEF HISTORY OF USE CASE BASICS VOL. 2, NO. 2 JOURNAL OF OBJECT TECHNOLOGY 113 3a. Student is a foreign student with pre-registered scholarship: 3a1. The system shows the capacity of free campus appartments. 3a2. The clerk assigns an appartment to the student ID. Rejoin at 3. Scenarios vs. Interaction Courses To fully comprehend the issues of use case business results and use case postconditions, the term scenario must be clearly understood. A use case scenario is a single path through the use case’s interaction courses. Figure 2 illustrates three interaction courses, i.e. one basic and two alternative courses. In fact, there are four scenarios: the sole basic course, basic course plus alternative course 1, the first part of the basic course and alternative course 2, and basic course with both alternative courses 1 and 2. Cockburn [3] refers to the basic course as the “main success scenario” because, if never branched by an alternative course, the basic course directly shows the use case goal succeeding.